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Telnet Authentication: Kerberos Version 5 


Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2000). All Rights Reserved. 
Abstract 


This document describes how Kerberos Version 5 [1] is used with the 
telnet protocol. It describes an telnet authentication suboption to 
be used with the telnet authentication option [2]. This mechanism 
can also used to provide keying material to provide data 
confidentiality services in conjunction with the telnet encryption 
option [3]. 


1. Command Names and Codes 

Authentication Types 
KERBEROS_V5 2 
Sub-option Commands 


AUTH 

REJECT 

ACCEPT 
RESPONSE 
FORWARD 
FORWARD_ACCEPT 
FORWARD_REJECT 


NUP WNEFR CO 
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Command Meanings 


TAC SB AUTHENTICATION IS <authentication-type-pair> AUTH <Kerberos V5 
KRB_AP_REQ message> IAC SE 


This is used to pass the Kerberos V5 [1] KRB_AP_REQ message to the 
remote side of the connection. The first octet of the 
<authentication-type-pair> value is KERBEROS_V5, to indicate that 
Version 5 of Kerberos is being used. The Kerberos V5 
authenticator in the KRB_AP_REQ message must contain a Kerberos V5 
checksum of the two-byte authentication type pair. This checksum 
must be verified by the server to assure that the authentication 
type pair was correctly negotiated. The Kerberos V5 authenticator 
must also include the optional subkey field, which shall be filled 
in with a randomly chosen key. This key shall be used for 
encryption purposes if encryption is negotiated, and shall be used 
as the negotiated session key (i.e., used as keyid 0) for the 
purposes of the telnet encryption option; if the subkey is not 
filled in, then the ticket session key will be used instead. 


If data confidentiality services is desired the ENCRYPT_US- 
ING_TELOPT flag must be set in the authentication-type-pair as 
specified in [2]. 


IAC SB AUTHENTICATION REPLY <authentication-type-pair> ACCEPT IAC SE 


This command indicates that the authentication was successful. 


If the AUTH_HOW_MUTUAL bit is set in the second octet of the 
authentication-type-pair, the RESPONSE command must be sent before 
the ACCEPT command is sent. 


IAC SB AUTHENTICATION REPLY <authentication-type-pair> REJECT 


<optional reason for rejection> IAC SE 


This command indicates that the authentication was not successful, 
and if there is any more data in the sub-option, it is an ASCII 
text message of the reason for the rejection. 


TAC SB AUTHENTICATION REPLY <authentication-type-pair> RESPONSE 
<KRB_AP_REP message> IAC SE 


Ts’o 


This command is used to perform mutual authentication. It is only 
used when the AUTH_HOW_MUTUAL bit is set in the second octet of 
the authentication-type-pair. After an AUTH command is verified, 
a RESPONSE command is sent which contains a Kerberos V5 KRB_AP_REP 
message to perform the mutual authentication. 
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IAC SB AUTHENTICATION <authentication-type-pair> FORWARD <KRB_CRED 
message> IAC SE 


This command is used to forward kerberos credentials for use by 
the remote session. The credentials are passed as a Kerberos V5 
KRB_CRED message which includes, among other things, the forwarded 
Kerberos ticket and a session key associated with the ticket. 

Part of the KRB_CRED message is encrypted in the key previously 
exchanged for the telnet session by the AUTH suboption. 


IAC SB AUTHENTICATION <authentication-type-pair> FORWARD_ACCEPT IAC 
SE 


This command indicates that the credential forwarding was 
successful. 


TAC SB AUTHENTICATION <authentication-type-pair> FORWARD_REJECT 
<optional reason for rejection> IAC SE 


This command indicates that the credential forwarding was not 
successful, and if there is any more data in the suboption, it is 
an ASCII text message of the reason for the rejection. 


Implementation Rules 


If the second octet of the authentication-type-pair has the AUTH_WHO 
bit set to AUTH_CLIENT_TO_SERVER, then the client sends the initial 
AUTH command, and the server responds with either ACCEPT or REJECT. 
In addition, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL, the 
server will send a RESPONSE before it sends the ACCEPT. 


If the second octet of the authentication-type-pair has the AUTH_WHO 
bit set to AUTH_SERVER_TO_CLIENT, then the server sends the initial 
AUTH command, and the client responds with either ACCEPT or REJECT. 
In addition, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL, the 
client will send a RESPONSE before it sends the ACCEPT. 


The Kerberos principal used by the server will generally be of the 
form "host/<hostname>@realm". That is, the first component of the 
Kerberos principal is "host"; the second component is the fully 
qualified lower-case hostname of the server; and the realm is the 
Kerberos realm to which the server belongs. 


Any Telnet IAC characters that occur in the KRB_AP_REQ or KRB_AP_REP 
messages, the KRB_CRED structure, or the optional rejection text 
string must be doubled as specified in [4]. Otherwise the following 
byte might be mis-interpreted as a Telnet command. 
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Examples 


User "joe" may wish to log in as user "pete" on machine "foo". If 
"pete" has set things up on "foo" to allow "joe" access to his 
account, then the client would send IAC SB AUTHENTICATION NAME "pete" 
IAC SE IAC SB AUTHENTICATION IS KERBEROS_V5 AUTH <KRB_AP_REQ MESSAGE> 
IAC SE 


The server would then authenticate the user as "joe" from the 
KRB_AP_REQ MESSAGE, and if the KRB_AP_REQ MESSAGE was accepted by 
Kerberos, and if "pete" has allowed "joe" to use his account, the 
server would then continue the authentication sequence by sending a 
RESPONSE (to do mutual authentication, if it was requested) followed 
by the ACCEPT. 


If forwarding has been requested, the client then sends IAC SB 
AUTHENTICATION IS KERBEROS_V5 CLIENT | MUTUAL FORWARD <KRB_CRED 
structure with credentials to be forwarded> IAC SE. If the server 
succeeds in reading the forwarded credentials, the server sends 
FORWARD_ACCEPT else, a FORWARD_REJECT is sent back. 


Client Server 
IAC DO AUTHENTICATION 
TAC WILL AUTHENTICATION 


[ The server is now free to request authentication information. 


] 


IAC SB AUTHENTICATION SEND 
KERBEROS_V5 CLIENT | MUTUAL 
KERBEROS_V5 CLIENT | ONE_WAY IAC 
SE 


[ The server has requested mutual Version 5 Kerberos 
authentication. If mutual authentication is not supported, 
then the server is willing to do one-way authentication. 


The client will now respond with the name of the user that it 
wants to log in as, and the Kerberos ticket. ] 


IAC SB AUTHENTICATION NAME 
"pete" IAC SE 

IAC SB AUTHENTICATION IS 
KERBEROS_V5 CLIENT | MUTUAL AUTH 
<KRB_AP_REQ message> IAC SE 


[ Since mutual authentication is desired, the server sends across 
a RESPONSE to prove that it really is the right server. ] 
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IAC SB AUTHENTICATION REPLY 
KERBEROS_V5 CLIENT | MUTUAL 
RESPONSE <KRB_AP_REP message> 
IAC SE 


[ The server responds with an ACCEPT command to state that the 
authentication was successful. ] 


IAC SB AUTHENTICATION REPLY 
KERBEROS_V5 CLIENT |MUTUAL ACCEPT 
IAC SE 


[ If so requested, the client now sends the FORWARD command to 
forward credentials to the remote site. ] 


IAC SB AUTHENTICATION IS KER- 
BEROS_V5 CLIENT | MUTUAL 

FORWARD <KRB_CRED message> IAC 
SE 


[ The server responds with a FORWARD_ACCEPT command to state that 
the credential forwarding was successful. ] 


IAC SB AUTHENTICATION REPLY 
KERBEROS_V5 CLIENT | MUTUAL 
FORWARD_ACCEPT IAC SE 


5. Security Considerations 


The selection of the random session key in the Kerberos V5 
authenticator is critical, since this key will be used for encrypting 
the telnet data stream if encryption is enabled. It is strongly 
advised that the random key selection be done using cryptographic 
techniques that involve the Kerberos ticket’s session key. For 
example, using the current time, encrypting it with the ticket 
session key, and then correcting for key parity is a strong way to 
generate a subsession key, since the ticket session key is assumed to 
be never disclosed to an attacker. 


Care should be taken before forwarding a user’s Kerberos credentials 
to the remote server. If the remote server is not trustworthy, this 
could result in the user’s credentials being compromised. Hence, the 
user interface should not forward credentials by default; it would be 
far safer to either require the user to explicitly request 
credentials forwarding for each connection, or to have a trusted list 
of hosts for which credentials forwarding is enabled, but to not 
enable credentials forwarding by default for all machines. 
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The IAC SB AUTHENTICATION NAME name IAC SE message is unprotected in 
this protocol. Its contents should be verified by a secure method 
after authentication completes before it is used. 


6. IANA Considerations 


The authentication type KERBEROS_V5 and its associated suboption 
values are registered with IANA. Any suboption values used to extend 
the protocol as described in this document must be registered with 
IANA before use. IANA is instructed not to issue new suboption 
values without submission of documentation of their use. 
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10. Full Copyright Statement 
Copyright (C) The Internet Society (2000). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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